1. The Field of the Invention
The present invention relates to systems and methods for restoring data in a database. More particularly, embodiments of the invention relate to systems and methods for restoring database data to a particular state corresponding to a specific point in time.
2. Related Technology
A database backup operation results in a duplicate copy of the data in a database. In the event of data corruption or data loss, the duplicate copy of the database data can be used to restore the database to the state the database existed in at the time that the backup operation was performed on the database. However, database backup operations can place a heavy demand on database system resources. Consequently, backup operations are generally performed periodically instead of continuously. This periodic backup schedule can result in data loss, however, when the database is modified subsequent to the most recent backup operation performed on the database. When the database is restored using the data contained in the backup copy of the database, those modifications to the database made subsequent to the most recent backup operation are lost.
Modifications, also known as transactions, made to a database are sometimes stored in a transaction log. A transaction log typically records information regarding each transaction executed on the database, such as the time that a transaction finished executing and the exact modification made to the database when the transaction was executed. Likewise, the sequence that each transaction was executed on the database is generally recorded in the transaction log. Some database backup operations create a duplicate copy of the data in the database, while other database backup operations simply create a copy of the transaction log or create a copy of only the data that has changed since the last full backup operation. A copy of the transaction log can be used in combination with a duplicate copy of the data in the database in restoring the data in the database.
At times, it may be desirable to restore the database to a point in time subsequent to the time of the most recent backup operation on the database. For example, if a transaction within the database subsequent to the most recent backup entered some data incorrectly, it would be desirable to restore the database to the state the database was in just prior to the incorrect entry. Sometimes a restore operation is necessary because of an unintentional loss or corruption of data. When an unintentional loss or corruption of data is identified by a user, it would be desirable to allow the user to restore the database to the database state that existed just prior to the unintentional loss or corruption of data.
One problem with current implementations of point-in-time restore operations is that a database administrator is often required to manually formulate and manually send one or more command line database queries to the database system before each stage of the point-in-time restore operation. These queries are required in order to determine which backup or backups to restore and, where there are multiple backups, the order in which to restore the backups. Since a point-in-time restore operation may require that multiple backups be restored in a certain order, a database administrator can, at an intermediate stage of the point-in-time restore, lose track of which backups have been restored and which backups remain unrestored. The only way a database administrator can determine which backups are still unrestored is to manually formulate one or more queries requesting this information from the database system. The formulation of database queries is time consuming and database administrators can make mistakes in syntax that can cause the query to return an error or return erroneous results. The inability to automatically determine which backups are unrestored at any point in point-in-time restore operation makes the task of executing a point-in-time restore operation burdensome and inefficient for a database administrator.
Another problem with current implementations of point-in-time restore operations is that, in order to restore each backup version, the database administrator is required to formulate a complex command line database command. The formulation of database commands presents obstacles similar to the formulation of database queries. Formulating a database command is time consuming and a database administrator can make mistakes in syntax that can cause the command, when executed, to return an error or return erroneous results. The requirement that a complex command be formulated in order to restore each backup version during a point-in-time restore operation makes the task of executing each stage burdensome and inefficient for a database administrator.
Yet another problem with current implementations of point-in-time restore operations is that the database administrator may need to make a backup copy of the transaction log of the database just prior to beginning the point-in-time restore operation. Where the desired point in time for the restore operation is after the most recent backup of the database, the only way to restore the database to the desired point in time is to make a backup copy of the transaction log before restoring any of the database backup versions, since restoring the database backup versions overwrites the database and therefore the transaction log is deleted from the database. A database administrator might forget to make a backup of a the transaction log before beginning the database restore operation, and thereby foreclose the possibility of a point-in-time restore operation where the desired point in time is subsequent to the time of the most recent backup of the database. Likewise, even where the database administrator does remember to make a backup copy of the transaction log, doing so requires the database administrator to formulate a complex transaction log backup command. Formulation of this command is time consuming and a database administrator can make mistakes in syntax that cause the command to fail when executed. The requirement that a complex command be formulated in order to backup the transaction log prior to beginning a point-in-time restore operation makes this task burdensome and inefficient for a database administrator.